Preserve rollup invalidations during concurrent refreshes - #1691

Greptile Summary

This PR replaces cache-backed dashboard invalidation with a durable per-user generation, builds rollups from a repeatable-read snapshot and permits a pending per-user follow-up refresh.

• Adds users.dashboard_rollup_generation and stores the consumed generation in the total rollup.
• Reworks refresh scheduling and GoodJob concurrency so invalidations during a refresh can trigger another job.
• Adds database-backed concurrency coverage and updates architecture documentation.
• The read-triggered scheduling change can still allow one dashboard response to combine fresh aggregate calculations with stale rollup fragments.

Confidence Score: 4/5

The PR should not merge until fingerprint-detected staleness also prevents stale dashboard fragments from being returned.

The durable generation and repeatable-read refresh address the primary concurrent invalidation race, but replacing schedule_for with enqueue_for leaves the generation clean when the existing source fingerprint detects staleness, allowing one dashboard response to mix fresh and stale data.

Files Needing Attention: app/services/dashboard_stats.rb

Important Files Changed

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  H[Heartbeat or historical correction] --> G[Increment durable user generation]
  G --> Q[Enqueue refresh]
  Q --> T[Repeatable-read transaction]
  T --> S[Read heartbeat snapshot and generation]
  S --> R[Atomically replace rollup rows]
  R --> C{Stored generation matches current generation?}
  C -->|Yes| D[Rollup is clean]
  C -->|No| F[Enqueue follow-up refresh]
  V[Dashboard detects fingerprint mismatch] --> E[Enqueue without generation increment]
  E --> X[Other fragments may still accept stale rollups]

### Issue 1
app/services/dashboard_stats.rb:269
**Stale fragments remain trusted**

When the total row’s heartbeat fingerprint is stale but its generation still matches, this only enqueues a refresh without marking the rollup dirty. The default dashboard then accepts the old activity graph, today stats, filter options and coding rhythm, causing the response to mix fresh aggregate calculations with stale fragments until the asynchronous refresh completes.

```suggestion
    DashboardRollupRefreshJob.schedule_for(user.id, wait: wait)
```

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

_{Reviews (1): Last reviewed commit: "Preserve rollup invalidations across con..." | Re-trigger Greptile}